О'екгно-СУБД
Зміст
1. 20 років еволюції програмного забезпечення.
2. Реляційні бази даних.
3. Об'єктно-реляційні методи.
4. Об'єктно-орієнтовані бази даних.
4.1 Why ODBMS?
4.2 Спірні моменти технології.
4.3 Стандарти об'єктних баз даних.
4.4 Постачальники ООСУБД.
5. Висновок.
6. Глосарій
1. 2. 20 років еволюції програмного забезпечення.Управління інформацією завжди було основною сферою застосування комп'ютерів, і, треба думати, буде грати ще більшу роль у майбутньому. Системи управління базами даних [1] (СУБД, DBMS - Database Management System) протягом всього шляху розвитку комп'ютерної техніки вдосконалювалися, підтримуючи все більш складні рівні абстрактних даних, заданих користувачем, і забезпечуючи взаємодію компонентів, розподілених в глобальних мережах і поступово інтегруються з телекомунікаційними системами. Дозволивши собі міркування в стилі Біла Гейтса, припустимо, що результатом буде становлення систем управління інформацією однієї з частин повсякденному житті кожного.
Історія розвитку комп'ютерної техніки - це історія безперервного руху від мови та рівня комунікації машини до рівня користувача. Якщо перші машини вимагали від користувача оформлення того, що йому потрібно (тобто написання програм), в машинних кодах, то мови програмування четвертого рівня (4GLs) дозволяли кінцевим користувачам, які не є професійними програмістами, отримувати доступ до інформації без детального опису кожного кроку, але тільки з вбудованими зумовленими типами даних - наприклад, таблицями.
Останнім кроком у цьому напрямку стала об'єктно-орієнтована технологія, радикально змінила сферу розробки програмного забезпечення вже в 1990-х роках (Малюнок 1). Об'єктно-орієнтований підхід дозволяє упаковувати дані та код для їх обробки разом. Таким чином практично знімається обмеження на типи даних, дозволяючи працювати на будь-якому рівні абстракції.
Еволюція систем управління інформацією йшла паралельно цьому прогресу, починаючи з низькорівневих програм, які, наприклад, безпосередньо виробляли операції читання і запису з усією пам'яттю без обмеження доступу, стрічкою, циліндрами і доріжками диска і більше високорівневими засобами - файловими системами, які оперували з такими поняттями , як масиви, записи та індекси для підвищення продуктивності. Бази даних у свою чергу починали з моделі записів та індексів (ISAM та ін), набуваючи з часом здатність відновлення після збоїв, перевірки цілісності даних і робота декількох користувачів одночасно. Ці ранні моделі даних (CODASYL) належали радше до рівня машинної орієнтації. Надалі реляційні бази даних, що прийшли на зміну в 1980-х роках, придбали механізм запитів, що дозволяє користувачеві вказати необхідну, надавши СУБД самої оптимальним чином знайти результат, використовуючи динамічну індексацію.
Об'єктно-орієнтовані СУБД (ООСУБД) стали розроблятися з середини 80-х років в основному для підтримки додатків САПР. Складні структури даних систем автоматизованого проектування виявилося дуже зручно оформляти у вигляді об'єктів, а технічні креслення простіше зберігати в базі даних, ніж у файлах. Це дозволяє обійтися без декомпозиції графічних структур на елементи і запису їх у файли після завершення роботи з кресленням, виконання зворотної операції при внесенні будь-якої зміни. Якщо типові реляційні бази даних мають зв'язку глибиною у два рівні, то ієрархічна інформація креслень САПР зазвичай включає близько десяти рівнів, що потребує досить складних операцій для "складання" результату. Об'єктні бази даних добре відповідали подібним завданням, і еволюція багатьох СУБД почалася саме з ринку САПР.
Тим часом ринок САПР був швидко насичений, і на початку 90-х років виробники ООСУБД звернули увагу на інші області застосування, вже міцно зайняті реляційними СУБД. Для цього треба було оснастити ООСУБД функціями оперативної обробки транзакцій (OLTP), утилітами адміністратора баз даних (database administrator - DBA), коштами резервного копіювання / відновлення і т. д. Роботи в даному напрямку тривають і сьогодні, але вже можна сказати, що перехід до комерційних додатків йде досить успішно.
3. Реляційні бази даних.У реляційних базах даних (Relational Database System, RDBS) всі дані відображаються в двовимірних таблицях. База даних, таким чином, це ні що інше, як набір таблиць. RDBS і орієнтовані на записі системи організовані на основі стандарту B-Tree чи методі доступу, заснованому на індексації - Indexed Sequential Access Method (ISAM) і є стандартними системами, що використовуються в більшості сучасних програмних продуктів. Для забезпечення комбінування таблиць для визначення зв'язків між даними, які практично повністю відсутні в більшості програмних реалізацій B-Tree і ISAM, використовується мови, подібні SQL (IBM), Quel (Ingres) і RDO (Digital Equipment), причому стандартом галузі в даний час стала мова SQL, підтримуваний всіма виробниками реляційних СУБД.
Оригінальна версія SQL - це інтерпретована мова, призначена для виконання операцій над базами даних. Мова SQL був створений на початку 70-х як інтерфейс для взаємодії з базами даних, заснованими на новій для того часу реляційної теорії. Реальні програми зазвичай написані на інших мовах, що генерують код мовою SQL і передавальних в СУБД у вигляді тексту в форматі ASCII. Потрібно відзначити також, що практично всі реальні реляційні (і не тільки реляційні) системи крім реалізації стандарту ANSI SQL, відомого зараз в останній редакції під ім'ям SQL2 (або SQL-92), включають в себе додаткові розширення, наприклад, підтримка архітектури клієнт-сервер або засоби розробки додатків.
Рядки таблиці складені з полів, заздалегідь відомих базі даних. У більшості систем не можна додавати нові типи даних. Кожен рядок у таблиці відповідає одному запису. Положення цього рядка може змінюватися разом з видаленням або вставкою нових рядків.
Щоб однозначно визначити елемент, йому повинні бути зіставлені поле чи набір полів, які гарантують унікальність елемента всередині таблиці. Таке поле або поля називаються первинним ключем (primary key) таблиці і часто є числами. Якщо одна таблиця містить первинним ключ іншої, це дозволяє організувати зв'язок між елементами різних таблиць. Це поле називається зовнішнім ключем (foreign key).
Так як всі поля однієї таблиці повинні містити постійне число полів заздалегідь визначених типів, доводиться створювати додаткові таблиці, що враховують індивідуальні особливості елементів, за допомогою зовнішніх ключів. Такий підхід сильно ускладнює створення скільки-небудь складних взаємозв'язків в базі даних. Бажаючим переконається, що це дійсно так і не пошкодував на це певний відрізок часу, компанія POET Software люб'язно надає можливість ознайомитися з прикладом у своїй "білій книзі" "POET Technical Reference". База даних рядового підприємства громадського харчування (клієнти - Джордж Буш і Едді Мерфі) складається з чотирьох таблиць.
Ще один великий недолік реляційних баз даних - це висока трудомісткість маніпулювання інформацією та зміни зв'язків.
4. Об'єктно-реляційні методи.Незважаючи на вищезгадані в п. 3 недоліки реляційних баз даних, вони мають ряд переваг:
поділ таблиць різними програмами;
розгорнутий "код повернення" при помилках;
висока швидкість обробки запитів (команда SELECT мови SQL; результатом вибірки є таблиця, яка містить поля, що задовольняють заданому критерію);
|
сама концепція об'єктних баз даних досить складна і вимагає від програмістів серйозного і тривалого навчання;
відносно висока швидкість при роботі з великими обсягами даних.
Крім того, в усьому світі значні кошти вже інвестовані в реляційні СУБД. Багато організацій не впевнені, що витрати, пов'язані з переходом на об'єктні бази даних, окупляться.
Тому багато користувачів зацікавлені в комбінованому підході, який би їм дозволив скористатися перевагами об'єктних баз даних, не відмовляючись повністю від своїх реляційних БД. Такі рішення дійсно існують. Якщо перехід від реляційної бази до об'єктної обходиться занадто дорого, то застосування останньої в якості розширення та доповнення реляційних СУБД часто є більш економічною альтернативою. Компромісні рішення дозволяють дотримати баланс між об'єктами і реляційними таблицями (Малюнок 2).
Об'єктно-реляційні адаптери. Цей метод передбачає використання так званого об'єктно-реляційного адаптера, який автоматично виділяє програмні об'єкти і зберігає їх у реляційних базах даних. Об'єктно-орієнтовані додаток працює як рядовий користувач СУБД. Незважаючи на деяке зниження продуктивності, такий варіант дозволяє програмістам повністю сконцентруватися на об'єктно-орієнтованої розробки. Крім того, всі наявні на підприємстві програми як і раніше можуть звертатися до даних, що зберігаються у реляційній формі.
Деякі об'єктні СУБД, наприклад GemStone компанії GemStone Systems, можуть самі виконувати роль потужного об'єктно-реляційного адаптера, дозволяючи об'єктно-орієнтованим додаткам звертатися до реляційних БД.
Об'єктно-реляційні адаптери, такі як Odapter компанії Hewlett-Packard для СУБД Oracle, можна з успіхом використовувати в багатьох областях, наприклад в якості сполучного ПО, що об'єднує об'єктно-орієнтовані програми з реляційними СУБД.
Об'єктно-реляційні шлюзи. При використанні такого методу користувач взаємодіє з БД за допомогою мови ООСУБД, а шлюз замінює всі об'єктно-орієнтовані елементи цієї мови на їх реляційні компоненти. За це знову доводиться розплачуватись продуктивністю. Наприклад, шлюз повинен перетворити об'єкти в набір зв'язків, згенерувати оригінальні ідентифікатори (original identifier - OID) об'єктів і передати це в реляційну БД. Потім шлюз повинен кожен раз, коли використовується інтерфейс реляційної СУБД, перетворювати OID, знайдений у базі, у відповідний об'єкт, збережений у РСУБД.
Продуктивність в розглянутих двох підходах залежить від способу доступу до реляційної бази даних. Кожна РСУБД складається з двох рівнів: рівня управління даними (data manager layer) та рівня управління носієм (storage manager layer). Перший з них обробляє оператори на мові SQL, а другий відображає дані в базу. Шлюз чи адаптер можуть взаємодіяти як з рівнем даних (тобто звертатися до РСУБД за допомогою SQL), так і з рівнем носія (викликами процедур низького рівня). Продуктивність в першому випадку набагато нижче (наприклад, система OpenODB фірми Hewlett-Packard, яка може виконувати роль шлюзу, підтримує лише на високому рівні).
Гібридні СУБД. Ще одним рішенням може стати створення гібридних об'єктно-реляційних СУБД, які можуть зберігати і традиційні табличні дані, і об'єкти. Багато аналітиків вважають, що майбутнє за такими гібридними БД. Провідні постачальники реляційних СУБД починають (або планують) додавати до своїх продуктів об'єктно-орієнтовані засоби. Зокрема, Sybase і Informix збираються в наступних версіях СУБД ввести підтримку об'єктів. Подібні розробки мають намір вести і незалежні фірми. Наприклад, компанія Shores готується оснастити об'єктно-орієнтованими засобами СУБД Oracle8, випуск якої намічений на кінець 1996 р.
З іншого боку, виробники об'єктних СУБД, такі як компанія Object Design, усвідомлюють, що об'єктно-орієнтовані бази даних у доступному для огляду майбутньому не замінять реляційні СУБД. Це змушує їх створювати шлюзи для підтримки реляційних та ієрархічних баз даних йди різного роду інтерфейси, характерним прикладом яких є об'єктно-реляційний інтерфейс Ontos Integration Server фірми Ontos, який використовується разом з її ООБД Ontos / DB.
5. Об'єктно-орієнтовані бази даних. 5.1 Why ODBMS?"Білими книгами" з назвою, винесеним у заголовок, з надлишком забезпечить будь-яка компанія, що займається об'єктними базами даних. Дещо про переваги і недоліки об'єктно-орієнтованих СУБД вже згадувалося вище, підіб'ємо у такому випадку підсумок.
Об'єктно-орієнтовані бази даних застосовуються з кінця 1980-х для забезпечення управління базами даних додатками, побудованими відповідно до концепції об'єктно-орієнтованого програмування. Об'єктна технологія розширює традиційну методику розробки додатків новим моделюванням даних і програмних засобів. Для повторного використання коду і поліпшення схоронності цілісності даних в об'єктному програмуванні дані та код для їх обробки організовані в об'єкти. Таким чином, практично повністю знімаються обмеження на типи даних.
Якщо дані складаються з коротких, простих полів фіксованої довжини (ім'я, адреса, баланс банківського рахунку), то кращим рішенням буде застосування реляційної бази даних. Якщо, проте, дані містять вкладену структуру, динамічно змінюваний розмір, визначені користувачем довільні структури (мультимедіа, наприклад), представлення їх в табличній формі буде, як мінімум, непростим. У той же час в ООСУБД кожна певна користувачем структура - це об'єкт, безпосередньо керований базою даних.
У РСУБД зв'язку управляються користувачем, створює зовнішні ключі. Потім для виявлення зв'язків динамічно під час виконання система переглядає дві (або більше) таблиці, порівнюючи зовнішні ключі до досягнення відповідності. Цей процес, званий об'єднанням (join), є слабкою стороною реляційної технології. Більше двох або трьох рівнів об'єднань - сигнал, щоб шукати найкраще рішення. У ООСУБД користувач просто оголошує зв'язок, і СУБД автоматично генерує методи управління, динамічно створюючи, видаляючи і перетинаючи зв'язку. Посилання при цьому прямі, немає необхідності в перегляді та порівнянні або навіть пошуку індексу, який може сильно позначитися на продуктивності. Таким чином, застосування об'єктної моделі краще для баз даних з великою кількістю складних зв'язків: перехресних посилань, посилань, що пов'язують декілька об'єктів з декількома (many-to-many relationships) двонаправленими посиланнями.
На відміну від реляційних, ООСУБД повністю підтримують об'єктно-орієнтовані мови програмування. Розробники, які застосовують С + + або Smalltalk, мають справу з одним набором правил (що дозволяють використовувати такі переваги об'єктної технології, як наслідування, інкапсуляція і поліморфізм). Розробник не повинен вдаватися до трансляції об'єктної моделі в реляційну і назад. Прикладні програми звертаються і функціонують з об'єктами, збереженими в базі даних, яка використовує стандартну об'єктно-орієнтовану семантику мови та операції. Навпаки, реляційна база даних вимагає, щоб розробник транслював об'єктну модель до підтримуваної моделі даних і включив підпрограми, щоб забезпечити це відображення під час виконання. Наслідком є додаткові зусилля при розробці і зменшення ефективності.
І, нарешті, ООСУБД підходять (знову ж таки без трансляцій між об'єктної і реляційної моделями) для організації розподілених обчислень. Традиційні бази даних (у тому числі і реляційні та деякі об'єктні) побудовані навколо центрального сервера, що виконує всі операції над базою. По суті, ця модель мало відрізняється від мейнфреймовой організації 60-х років з центральною ЕОМ - мейнфреймів (mainframe), що виконує всі обчислення, і пасивних терміналів. Така архітектура має ряд недоліків, головним з яких є питання масштабованості. В даний час робочі станції (клієнти) мають обчислювальну потужність порядку 30 - 50% потужності сервера бази даних, тобто велика частина обчислювальних ресурсів розподілена серед клієнтів. Тому все більше додатків, і в першу чергу бази даних і засоби прийняття рішень, працюють в розподілених середовищах, в яких об'єкти (об'єктні програмні компоненти) розподілені по багатьох робочих станцій і серверів і де будь-який користувач може отримати доступ до будь-якого об'єкту. Завдяки стандартам межкомпонентного взаємодії (про це пізніше) всі ці фрагменти коду комбінуються один з одним незалежно від апаратного, програмного забезпечення, операційних систем, мереж, компіляторів, мов програмування, різних засобів організації запитів і формування звітів і динамічно змінюються при маніпулюванні об'єктами без втрати працездатності .
5.2 Спірні моменти технології.Всі ООСУБД за визначенням підтримують збереження і розділення об'єктів. Але, коли справа доходить до практичної розробки додатків на різних ООСУБД, виявляється безліч відмінностей у реалізації підтримки трьох характеристик:
Цілісність;
Масштабованість;
Відмовостійкість.
Відзначимо, що ООБД не потребують багатьох з тих внутрішніх функцій і механізмів, які настільки звичні і необхідні в реляційних БД. Наприклад, при невеликому числі користувачів, довгих транзакціях і незначною завантаженні сервера об'єктні СУБД не потребують підтримки складних механізмів резервного копіювання / відновлення (історично склалося так, що перші ООБД проектувалися для підтримки невеликих робочих груп - близько десяти чоловік - і не були пристосовані для обслуговування сотень користувачів). Проте технологія БД визначено дозріла для великих проектів.
Для ілюстрації першої категорії розглянемо механізм кешування об'єктів. Більшість об'єктних СУБД поміщають код додатки безпосередньо в той же адресний простір, де працює сама СУБД. Завдяки цьому досягається підвищення продуктивності часто в 10-100 разів у порівнянні з окремими адресними просторами. Але при такій моделі об'єкт з помилкою може пошкодити об'єкти і зруйнувати базу даних.
Існують два підходи до організації реакції СУБД для запобігання втрати даних. Більшість систем передають додатком покажчики на об'єкти, і рано чи пізно такі покажчики обов'язково стають невірними. Так, вони завжди неправильні після переходу об'єкта до іншого користувача (наприклад, після переміщення на інший сервер). Якщо програміст, який розробляє додаток, пунктуальний, то помилки не виникає. Якщо ж додаток спробує застосувати покажчик у непідходящий для цього момент, то в кращому випадку відбудеться крах системи, в гіршому - буде втрачено інформація в середині іншого об'єкта і порушиться цілісність бази даних.
Є метод, кращий, ніж використання прямих покажчиків (Малюнок 3). СУБД додає додатковий покажчик і при необхідності, якщо об'єкт переміщається, система може автоматично вирішити ситуацію (перезавантажити, якщо це необхідно, об'єкт) без виникнення конфліктної ситуації.
Існує ще одна причина для застосування непрямої адресації: завдяки цьому можна відстежувати частоту викликів об'єктів для організації ефективного механізму свопінгу.
Це необхідно для реалізації вже другого необхідного властивості баз даних - масштабованості. Знову слід згадати організацію розподілених компонентів. Класична схема клієнт-сервер, де основне навантаження припадає на клієнта (така архітектура називається ще "товстий клієнт-тонкий сервер"), краще справляється з цим завданням, ніж мейнфреймовая структура, однак її все одно не можна масштабувати до рівня підприємства. Завдяки багатоланкової архітектури клієнт-сервер (N-Tier architecture) відбувається рівномірний розподіл обчислювального навантаження між сервером і кінцевим користувачем. Навантаження розподіляється за трьома і більше ланкам, що забезпечує додаткову обчислювальну потужність. До чого ж ще веде така практика? "Архітектура клієнт-сервер, ще зовсім недавно вважалася складною середовищем, поступово перетворилася на виключно складну середу. Чому? Завдяки прискореному переходу до використання систем клієнт-сервер декількох ланок "(PCMagazine). Розробникам доводиться розплачуватися додатковими труднощами, великими витратами часу і безліччю проблем, пов'язаних з інтеграцією. Залишимо чергове згадка розподілених компонентів цього не позбавленою оптимізму ноті.
Третє необхідну якість бази даних - це відмовостійкість. Саме ця властивість відрізняє програмний продукт від "прилади". Існують кілька способів забезпечення відмовостійкості:
резервне копіювання та відновлення;
розподіл компонентів;
незалежність компонентів;
копіювання.
Керуючись першим принципом, програміст визначає потенційно небезпечні ділянки коду і вставляє в програму деякі дії, що відповідають початку транзакції - збереження інформації, необхідної для відновлення після збою, і закінчення транзакції - відновлення або, у разі неможливості, прийняття якихось інших заходів, наприклад, відправка повідомлення адміністратору. У сучасних СУБД цей механізм забезпечує відновлення у разі виникнення практично будь-якої помилки системи, додатки або комп'ютера, хоча, звичайно, не можна говорити про ідеальну захисту від збоїв.
У мейнфреймовой архітектурі єдиним джерелом збоїв була центральна ЕОМ. При переході до розподіленої багатоланкової організації помилки можуть викликати не тільки комп'ютери, включені в мережу, але й комунікаційні канали. У багатоланкової архітектури при збої одного з ланок без спеціальних заходів результати роботи інших виявляться марними. Тому при розробці розподілених систем забезпечується принципово вищий рівень забезпечення відмовостійкості. Назвемо обов'язкові для сучасних розподілених СУБД властивості:
прозорий доступ до всіх об'єктів незалежно від їх місця розташування, завдяки чому користувачеві доступні всі сервіси СУБД і може проводитися перерозподіл компонентів без небажаних наслідків.
так званий "трифазний монітор транзакцій" (third-party transaction monitor), завдяки якому транзакція виконується не в два, а в три етапи - спочатку надсилається запит про готовність до транзакції.
Що станеться, якщо один з компонентів вийде з ладу? Система, створена відповідно тільки з вищевикладеними аргументами, призупинить роботу всіх користувачів і перерве всі транзакції. Тому важливо таку властивість СУБД, як незалежність компонентів.
При мережному збої мережа розділяється на частини, компоненти кожної з яких не можуть єднатися з компонентами іншій частині. Для того, щоб зберегти можливість роботи усередині кожної такої частини, необхідно дублювання критично важливої інформації всередині кожного сегмента. Сучасні системи дозволяють адміністратору бази даних динамічно визначати сегменти мережі, варіюючи таким чином рівень надійності всієї системи в цілому.
І, нарешті, про копіювання (replication) даних. Найпростішим способом є додавання до кожного (основному) серверу резервного. Після кожної операції основний сервер передає змінені дані резервному, який автоматично включається у разі виходу з ладу основного. Природно, така схема не позбавлена недоліків. По-перше, це призводить до значних накладних витрат при дублюванні даних, що не тільки позначається на продуктивності, але і саме по собі є потенційним джерелом збоїв. По-друге, у разі збою, що спричинило за собою розрив з'єднання між двома серверами, кожен з них повинен буде працювати у своєму сегменті мережі як основного сервера, причому зміни, зроблені на серверах за час роботи в такому режимі, буде неможливо синхронізувати навіть після відновлення працездатності мережі.
Більш досконалим є підхід, коли створюється необхідне (подбираемое відповідно з необхідним рівнем надійності) число копій в сегменті. Таким чином збільшується доступність копій і навіть (при розподілі навантаження між серверами) підвищується швидкість читання. Проблема неможливості поновлення даних декількома серверами одночасно у разі їх взаємної недоступності вирішується за рахунок дозволу проведення модифікацій тільки в одному із сегментів, наприклад має найбільше число користувачів. При добре налаштованої схемою кешування витрати на накладні витрати при дублюванні модифікованих даних близькі до нуля.
5.3 Стандарти об'єктних баз даних.Для забезпечення переносимості додатків (додаток може працювати на різних СКБД) та сумісності з СУБД (може взаємодіяти з різними СУБД), природно, необхідне вироблення стандартів. Відразу зауважимо, що встановлення стандартів позбавляє виробника в деякій мірі свободи в прийнятті рішень і збільшує вартість продукту за рахунок ліцензійних відрахувань і більше не будемо обговорювати доцільність (прямо скажемо, очевидну) стандартизації.
В області об'єктних СУБД в даний час вироблені стандарти для:
об'єктної моделі;
мови опису об'єктів;
мови організації запитів (Object Query Language - OQL);
"Сполучного" мови (C + + і, звичайно ж, Smalltalk);
адміністрування;
обміну (імпорт / експорт);
інтерфейсів інструментарію та ін
Хоча в Microsoft і свою думку з цього приводу, організацією, що виробила найбільш використовувані на сьогодні й усталені стандарти, є консорціум постачальників ООСУБД ODMG (ООСУБД), якого підтримують практично всі діючі особи галузі. У співпраці з OMG, ANSI, ISO та іншими організаціями був створений стандарт ODMG-93. Цей стандарт включає в себе кошти для побудови закінченого додатка, яке буде працювати (після перекомпіляції) у будь-якій сумісній з цією специфікацією ООСУБД. До книги ODMG-93 входять наступні розділи:
Мова визначення об'єктів (Object Definition Language - ODL);
Мова об'єктних запитів (Object Query Language - OQL);
Зв'язування з C + +;
Зв'язування з Smalltalk.
ODL. В якості мови визначення об'єктів (ODL) ODMG був обраний існуючий мова IDL (Interface Definition Language - мова опису інтерфейсів), який був доповнений такими необхідними для об'єктних БД властивостями, як визначення колекцій, двонаправлених зв'язків типу "багато-до-багатьох" , ключів та ін У поєднанні із засобами мови IDL визначення атрибутів і операцій, це дозволяє визначати практично будь-які об'єкти. Всі доповнення реалізовані у вигляді довизначення методів, що забезпечує сумісність зі стандартами OMG, наприклад стандартом CORBA.
Малюнок 4 показує працездатну схему для побудови програми на стандартних мовах програмування, в процесі якої автоматично генеруються метадані, заголовки та методи. Наведемо також приклад мовою ODL з "білої книги" компанії Objectivity, який ілюструє зв'язку типу "один-до-багатьох", оголошені між викладачем і студентами:
interface professor: employee {
attribute string name;
unique attribute lang unsigned ssn;
relationship dept works_in inverse faculty; relationship set teaches inverse taught_by;. . . operations. . .
{
interface section: class {
. . . taught_by: professor. . . ;
. . .
}
OQL. За основу мови OQL була взята команда SELECT мови SQL2 (або SQL-92) і додані можливість направляти запит до об'єкта чи колекції об'єктів і можливість викликати методи в рамках одного запиту. Дані, отримані в результаті запиту, можуть бути скалярними (включаючи кортежі), об'єктами або колекціями об'єктів. Деякі приклади на мові OQL (те ж джерело):
• Select x from x in faculty where x.salary>
x.dept.chair.salary
• sort s in (select struct (name: x.name, s: x.ssn) from
x in faculty where for all y in
x.advisees: y.agename = "Smith";
prof-> age + prof-> age +1;
На цьому, мабуть, почуття подяки компанії Objectivity значною мірою ослабне, тому що прикладів мовою Smalltalk знайти не вдалося.
Smalltalk. ODMG-93 підтримує ту ж об'єктну модель для Smalltalk, що і для С + +, IDL і запити на мові OQL; це дозволяє розділяти один і той самий об'єкт користувачам С + + і Smalltalk. Специфікація підтримує типи (можливі безтипових поля) і синтаксис оригінальної версії Smalltalk.
Взаємодія з іншими стандартами. Багато стандарти сумісні з об'єктними базами даних, наприклад STEP, CFI, TINA-C, ISO ODP, ANSI X3H7, OpenGIS та ін Зараз вони можуть безпосередньо взаємодіяти з будь-якої стандартної ООСУБД, хоча в деякі з них і були внесені зміни для забезпечення сумісності. Два інших стандарти заслуговують більш детального опису - OMG і SQL.
Стандарти OMG. Першим результатом діяльності OMG стало твердження (OMG не створює стандартів, а приймає одну з існуючих реалізацій) Архітектури Брокера об'єктних Запитів (Common Object Request Broker Architecture - CORBA) - кошти диспетчеризації запитів між об'єктами і користувачами; в подальшому були додані деякі сервіси . Інтерфейс ODMG зараз повністю адаптований до специфікації Persistence Object Service консорціуму OMG, що дозволяє користувачам систем, заснованих на архітектурі CORBA, користуватися перевагами від ООСУБД, які можуть містити об'єкти, що відповідають стандарту OMG і використовувані так само, як і будь-які інші ("дрібні") об'єкти специфікації OMG (Малюнок 5). Об'єкти OMG в свою чергу доступні через інтерфейс ODMG.
Мова SQL. Через поширеності SQL був закладений в основу OQL, який був доповнений засобами підтримки об'єктної моделі. В даний час розробляється версія мови SQL, відома під назвою SQL3, в якій будуть реалізована підтримка об'єктів і SQL буде приведений у відповідність сучасним поняттям про повноцінний мовою програмування. На відміну від ODMG, в SQL не планується прив'язка до ODL, а також C + + і Smalltalk, які важливі для користувачів ООСУБД. Незважаючи на це, можливості SQL3 в організації запитів збігаються з можливостями OQL. Коли SQL3 буде готовий (розробки ведуться зараз на ранній стадії обговорення основних питань щодо об моделі), ODMG, ймовірно, доповнить його, як це вже зроблено для С + + і Smalltalk.
5.4 Постачальники ООСУБД.Список сучасних комерційних об'єктно-орієнтованих систем включає в себе наступні продукти:
Objectivity / DB компанії Objectivity, Inc. (Остання версія - 2.1) ідеально, за заявами фірми, підходить для додатків, які працюють в розподілених середовищах, вимагають гнучкої модифікації даних, організації складних зв'язків, а також потребують високої продуктивності і роботи з великими обсягами даних. Ймовірно, всі компанії, що виробляють ООСУБД, ставлять за мету скласти таке враження щодо власних розробок у читачів поширюваних ними документів (хоча деякі і роблять це в більш делікатній формі). Більш змістовно, Objectivity забезпечила інтеграцію інструментарію СУБД і розробки додатків з такими засобами програмування, як SoftBench і C + + SoftBench. Завдяки інтегрованому графічному інтерфейсу розробки схеми БД і інструментам налагодження та аналізу спрощується завдання моделі бази даних і, відповідно, розробки додатків для Objectivity / DB.
СУБД GemStone корпорації GemStone Systems, Inc. Відома в останній редакції під номером 5.0. GemStone традиційно зосереджена на ринку Smalltalk (хоча не так давно і була випущена версія для С + +) і має замовників, здатних продемонструвати на виробництві великомасштабні, цільові застосування її продуктів. На жаль, списком цих замовників обсяг інформації, яку компанія хоче донести до цікавляться (WWW), обмежується.
ONTOS Corp., Розробник СУБД ONTOS (хто б подумав), за традицією займається розвитком сервера об'єктно-орієнтованої СУБД, але останнім часом надає особливого значення своїм Службам Інтеграції Об'єктів (Object Integration Services).
Побудована на основі реляційної СУБД AllBase, система OpenODB фірми Hewlett-Packard також, як і Objectivity / DB, інтегрована з системою SoftBench й існує у версії для С + +. Завдяки глибокій інтеграції, SoftBench розпізнає файли додатків OpenODB для установки оптимальної конфігурації, може створювати бази даних формату OpenODB зі своєї інтегрованого середовища, забезпечує оперативну допомогу з середовища розробки і т. д.
Object Design Inc. Зі своєю СУБД ObjectStore займає лідируюче положення в галузі, здійснюючи близько 33% поставок на ринку об'єктно-орієнтованих СУБД і остання модернізація системи (клієнт мови SQL і шлюз до реляційної СУБД) повинні лише зміцнити становище фірми. Object Design підтримує версії своєї СУБД як для С + +, так і для Smalltalk.
Versant Object Technology, Inc. (СУБД Versant) проводить подвійну стратегію, пропонуючи засіб забезпечення об'єктно-орієнтованої СУБД високого класу для телекомунікацій та інструментальні засоби Smalltalk для більш загальних випадків розробки додатків. Використовуючи розроблений фірмою інтерфейс VERSANT Smalltalk Language Interface, СУБД сумісна як з версією мови Smalltalk компанії ParcPlace-Digitalk, так і з Visual Age for Smalltalk корпорації IBM.
СУБД UniSQL компанії UniSQL Inc. - Добре усталена система, що дозволяє користувачам здійснювати запити і модифікацію бази за допомогою розробленого компанією мови SQL / X (подібні мови, що носять умовну назву Object SQL, розроблені і деякими іншими постачальниками). Вся БД UniSQL може складатися одночасно із зв'язків в локальних РСУБД і класів у локальних об'єктних базах UniSQL. Завдяки механізму каталогів, СУБД передає запити та модифікації даних в локальні бази даних і, обробивши (переклад в інший формат, групування, сортування і т. д.) отриманий від них результат, повертає його користувачеві.
Крім того ООСУБД пропонують: Object Database, Inc. (Object Database), Itasca Systems Inc. (Itasca) O2 Technology (O2) і деякі інші компанії.
6. Висновок.У 1996 р. намітився помітний зсув в галузі освоєння об'єктних СУБД. Вже є приклади практичного їх використання великими біржами, банками, страховими компаніями, а також у сфері виробництва і телекомунікацій, де баз даних, що містить гігабайти інформації, доводиться обслуговувати сотні користувачів. Вони виявилися хорошою альтернативою в тих випадках, коли застосування реляційних БД змушувало будувати складну схему з надмірно великим числом межтаблічних зв'язків.
Завдяки значному прогресу у розвитку об'єктної технології, за останні п'ять років виробникам вдалося довести свої ООСУБД до такого рівня, що вони стали цілком відповідати реальним вимогам ринку.
Незважаючи на те, що технологія об'єктних СУБД дозріла для великих проектів, для справді масового її розповсюдження необхідний спеціальний інструментарій.
На даний момент відчувається нагальна потреба в інтеграції ООСУБД з існуючими інструментальними засобами. Розробники вже сьогодні могли б продуктивно використовувати версії Visual Basic, Power Builder, Forte або Delphi, підтримують ООСУБД. Більшість продуктів для створення додатків в тій чи іншій мірі є об'єктно-орієнтованими, але працюють як і раніше з реляційними БД. Фахівці вважають, що партнерство виробників ООСУБД і засобів програмування здатне привести до появи такого необхідного інструментарію.
Експерти вже неодноразово оголошували наступний рік "роком об'єктних баз даних", проте зараз все говорить про те, що 1997 р. дійсно має шанси нарешті ним стати. Основними стимулами зростаючого інтересу до ООСУБД аналітики вважають розширення застосування мультітеліа-додатків і нових засобів, що поліпшують їх стикування з існуючими базами даних.
7. Глосарій
4 GL (4th Generation Language) - Мова програмування четвертого покоління ¨ Мова програмування, при створенні якого використовуються мови програмування третього рівня (3GL) - процедурні мови типу C та Pascal. 4GL простіше у використанні, ніж 3GL, їм зазвичай віддають перевагу при складанні програм обслуговування баз даних і застосовують у поєднанні з відповідними засобами розробки.
Blob (Binary Large Object) - Двійковий великий об'єкт, Блоб. ¨ Довгий лінійний блок даних (наприклад, цифрове зображення або відеокліп), який найбільш підходить для зберігання в ООСУБД.
CORBA (Common Object Request Broker Architecture) Архітектура брокера об'єктних запитів ¨ Стандарт взаємодії розподілених компонентів, розроблений OMG.
DBMS (Database Management System) - Система управління базами даних, СУБД
N - звенная архітектура (N-Tier Model) ¨ Архітектура клієнт-серврер, в якій застосовуються засоби розбиття програм або розподілені об'єкти для поділу обчислювального навантаження серед такої кількості серверів додатків, що необхідно при наявному рівні навантаження. При багатоланкової моделі системи кількість можливих клієнтських місць значно більше, ніж при використанні двухзвенной моделі. См також middleware.
ODBMS (Object Database Management System) - Об'єктно-орієнтована СУБД - ООСУБД. ¨ СУБД, що зберігає дані і взаємозв'язку між її елементами безпосередньо в самій базі даних у вигляді об'єктів, що містять, як правило, алгоритми обробки цих даних.
ODMG (Object Database Management Group) ¨ Консорціум виробників об'єктних баз даних для вироблення стандартів (ODMG-93, ODMG-95).
OMG (Open Management Group) ¨ Консорціум постачальників у сфері об'єктної технології для вироблення стандартів межкомпонентного взаємодії. Об'єднує практично всіх провідних виробників (більш ніж 500); членство Microsoft, мабуть, лише умовно.
OQL (Object Query Language) Мова об'єктних запитів ¨ Розроблений консорціумом ODMG мова опису запитів, за основу якого був прийнятий SQL-92.
RDBMS (Relational Database Management System) - Реляційна СУБД - СУБД, що зберігає взаємозв'язку між елементами у вигляді двовимірних таблиць і використовує для запитів мову SQL.
SQL (Structured Query Language) - Мова структурованих запитів ¨ інтерпретована мова, що описує операції (створення, обробка та витяг) над реляційними базами даних.
Архітектура клієнт-сервер (Client-server architecture) ¨ Архітектура, забезпечує розподіл навантаження між клієнтом і сервером. Зазвичай ці функції виконують два різних комп'ютера, об'єднаних за допомогою мережі.
Атрибути (Attributes) ¨ Видима за межами об'єкта інформація про стан цього об'єкта.
"Біла книга" (White Paper) ¨ Офіційне видання.
Гібриди (Hybrids) ¨ 1. Засоби зв'язку між світами об'єктних і реляційних баз даних, включаючи бази даних, які зберігають інформацію у реляційній формі, але використовують об'єктні буферні кошти. Див також об'єктно-реляційні методи 2. СУБД, які можуть зберігати та табличні дані, і об'єкти. Цього визначення я намагався дотримуватися.
Ідентичність (Identity) ¨ Можливість отримання унікального адреси об'єкта незалежно від його місця розташування і атрибутів.
Інкапсуляція (Encapsulation) ¨ Об'єднання даних та коду в один модуль - об'єкт, доступ до якого може здійснюватися тільки через суворо певний інтерфейс.
Метадані (Metadata) ¨ Дані, що є описом інших даних (наприклад, схема бази даних по відношенню до її вмісту).
Спадкування (Inheritance) ¨ Механізм, завдяки якому визначення класу поширюється на класи, що лежать нижче його в ієрархії узагальнення класів. Це дозволяє багаторазово змінювати визначення, вносячи в міру необхідності зміни, пов'язані зі спеціалізацією.
Об'єктно-реляційні методи (Object-relational Approaches) ¨ Підходи, що дозволяють скористатися перевагами об'єктних баз даних, не відмовляючись повністю від реляційних БД.
Відображення (Mapping) ¨ Процес встановлення зв'язків між додатками, побудованими навколо об'єктно-орієнтованих і реляційних баз даних.
Поліморфізм (Polymorphism) ¨ Здатність об'єктів різних класів і самих класів задовольняти одним і тим же протоколів або окремим повідомленням, виконуючи при цьому різні дії, передбачені їх власними методами.
Проміжне забезпечення (Middleware) ¨ ПЗ, що служить посередником між клієнтом і сервером, наприклад, для надання загальних інтерфейсів. Слідуючи традиції, і я теж напишу, що проміжне ПЗ - це слеш в терміні "клієнт / сервер".
Протокол (Protocol) ¨ Набір повідомлень, на які може відповісти клас (протокол класу) або його об'єкти (протокол об'єкта). Протокол визначається заданими методами. Всі об'єкти одного класу відповідають одному протоколу.
СУБД - Система Управління Базами Даних. ¨ Що лежить в основі бази даних прикладна програма, що виконує операції над збереженої інформацією.
Транзакція (Transaction) - обробка запиту ¨ Виконання елементарної цілісної операції над даними, протягом якої база даних знаходиться в нестійкому стані.
ООСУБД (ODBMS) - Об'єктно-Орієнтована Система Управління Базами Даних.